Typically, a designer of a controller for a system (e.g., a machine, an apparatus, etc.) with modular hardware (e.g., components, modules, etc.) designs the control software for the system without knowing the configuration (e.g., capabilities, constraints of the capabilities, etc.) of one or more of the components that make up the system. If fact, such knowledge may not be attainable until after the control software is loaded to the system, system power is cycled “on,” and the system boots up.
One technique that facilitates designing control software for such systems includes model-based planning. The model-based planning technique is based on a notion that each component of the system can send a model of its behavior to a central planner or controller. This assumes that a modeling language is available that can capture all the relevant information about each component's capabilities and constraints thereof and that the behavior of all possible future components can be captured as well. However, these assumptions typically are over-optimistic, or not achievable.
Conventionally, such models are written in a fixed language and transferred to the controller of the system. The controller interprets the models in order to determine the capabilities and constraints of the system components. Subsequently, upon receiving one or more jobs to process, the controller generates a plan to process the one or more jobs based on the components' capabilities and capability constraints described within each of the component models.
The plan is then validated via a propose/accept/confirm (PAC) protocol or other technique. With the PAC protocol, the plan is proposed to all of the components involved, as determined by the plan. Each of the components evaluates the proposed plan and responds to the controller by either accepting or rejecting the proposed plan. If all of the components accept the proposed plan, then the controller will confirm the plan. A confirmed plan is sent to an execution engine or the like for execution. If at least one of the components rejects the plan, then the controller generates a new plan, or re-plans. This cycle of generate a first plan, propose the first plan, reject the first plan, re-plan (generate a second plan), propose second plan, reject second plan, . . . , re-plan (generate plan X), propose plan X, etc. may continue until a plan is finally accepted by all of the components or be terminated without ever reaching a final plan.
By way of example, one or more of the component models may not capture one or more constraints of a component. Therefore, the controller may generate a plan that does not satisfy the unknown constraint and, thus, the plan is subsequently rejected by the corresponding component. Since the controller does not know why the plan was rejected (i.e., it is not aware of the constraint that is not being satisfied), the controller may generate a new or next plan that also does not satisfy the unknown constraint. As a result, the component will also reject this plan. Eventually, the controller may generate a plan that satisfies the unknown constraint and all of the components will accept the plan. However, the controller may never generate a plan that satisfies the unknown constraint and, thus, a plan may never by accepted by all of the components. In addition, each PAC cycle consumes time and cumulatively the time to get a confirmed plan may take tens, hundreds, thousands, etc. of milliseconds. Thus, even if a plan is eventually accepted, time and processing resources may have been wasted due to generating and testing plans based on the incomplete information.
In view of the above, there is an unresolved need for an improved planning technique.